Added an alternative way to generate first-order multiplets with better scaling#27
Added an alternative way to generate first-order multiplets with better scaling#27RaphaelRobidas wants to merge 2 commits intosametz:developfrom
Conversation
|
Brief response for now (traveling for the holidays): Good catch on the documentation error. When I get back from vacation I'll review your new version of the function. |
|
Two things:
|
|
I didn't know about As for the timing, I ran the benchmarks again and the new code is now as fast or faster as the current code: It seems that the implementation in the standard library is a bit faster than the one in Scipy. Overall, the new code does not seems to have drawbacks now. |
The current method of generating multiplets (splitting multiple times into doublets) scales exponentially with the multiplicity. An alternative way to generate multiplets was implemented using binomial coefficients. It's faster for high multiplicities (although slower for simple cases) while remaining pretty elegant. The code is not currently used by the other functions, I let you judge whether it would be useful to use elsewhere in the codebase.
Benchmark results:
Verification and benchmarking code:
I also noticed a slight confusion regarding the notation of the multiplicities. Currently, a coupling of the form
(8, 2)will produce a triplet withJ = 8 Hz, as it causes the signal to split twice. The docstring of the multiplet function previously indicated that(8, 2)would produce a doublet.